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Titel: Verfahren zum Debugger! rekdiif igurierbarer 

Architekturen 

5 Beschreibung 

Die vorliegende Erfindung befafit sich mit Verfahren fur das 
Debuggen von Prograiranen auf konf igurierbaren Architekturen. 
Unter einer rekonf igurierbaren Architektur werden u. a. Bau- 

10 steine (VPU) mit konf igurierbarer Funktion und/oder Vernet- 
zung verstanden, insbesondere integrierte Bausteine mit einer 
Mehrzahl von ein- Oder mehrdimensional angeordneten arithme- 
tischen und/oder logisqhen und/oder analogen und/oder spei- 
chernden und/oder vernetzenden Baugruppen (im Folgenden PAEs 

15 genannt) und/oder kommunikativen/peripheren Baugruppen (10), 
die direkt oder durch ein oder mehrere Bussystem(e) miteinan- 
der verbunden sind. PAEs sind in beliebiger Ausgestaltung, 
Mischung und Hierarchie angeordnet. Diese Anordnung wird im 
weiteren PAE-Array oder PA genannt. 

20 

Zur Gattung dieser Bausteine zahlen systolische Arrays, neu- 
ronale Netze, Mehrprozessor-Systeme, Prozessoren mit raehreren 
Rechenwerken und/oder logischen Zellen, Vernetzungs- und 
Netzwerkbausteine wie z.B. Crossbar-Schalter, ebenso wie be- 

25 kannte Bausteine der Gattung FPGA, DPGA, XPUTER, etc. Hinge- 
wiesen wird insbesondere in diesem Zusammenhang auf die fol- 
genden Schutzrechte desselben Anmelders: P 44 16 881.0-53, DE 
197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, 
DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, 

30 DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, 
DE 100 36 627,9-33, DE 100 28 397.7, DE 101 10 530.4, 
DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, 
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DE 102 06 856.9, 60/317,876, DE 102 02 044.2, DE 101 29 
237.6-53, DE 101 39 170.6. Diese sind hiermit zu Offenba- 
rungszwecken vollumfanglich eingegliedert . 

Weiterhin soli angemerkt warden, dafi die zu beschreibenden 
Verfahren auch auf Gruppen von mehreren Bausteinen angewendet 
werden kOnnen. Dennoch wird nachfolgend auf VPU und/oder auf 
//Bausteine"'"' Bezug genoinmen. Diese Bauteile und deren Betrieb 
sind noch zu verbessern. 

Die Aufgabe der vorliegenden Erfindung besteht darin, Neues 
ftir die gewerbliche Anwendung bereitzustellen. 

Die Losung der Aufgabe wird unabhangig beansprucht. Bevorzug- 
15 te Ausfuhrungsformen befinden sich in den Unteransprtichen . 



1. ErfinchangsgemaBes Verfahren 

20 Es werden nachfolgend mehrere Verfahrdn und Hardwareimplemen- 
tierungen vorgestellt, die ein effizientes Debuggen von VPU- 
Systemen ermoglichen. 

Das Debuggen erfolgt in einer bevorzugten Vafiante entweder 
25 durch die Verwendung eines entsprechend an eine VPU oder den 
Baustein angeschlossenen Microcontrollers oder durch eine 
Ladelogik nach den Patenten P 44 16 881.0-53, 
DE 196 51 075.9-53, DE 196 54 846.2-53, DE 196 54 593.5-53, 
DE 197 57 200.6-33, DE 198 07 872.2, DE 101 39 170.6, 
30 DE 199 26 538.0, DE 100 28 397.7, die durch Bezugnahme 

vollumfanglich eingegliedert sind. Wie ersichtlich sein wird, 
sind aber auch andere Hardware-Varianten verwendbar. 
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Folgende grundlegende Verfahren sollen alternativ und/oder 
gemeinsam dabei angewendet warden: 



5 1.1 Erkennen exner Debug-Bedlngung 

1.1.1 Bedingung 

Durch den Programmierer wird beispielsweise innerhalb des De- 
bug-Tools eine oder mehrere Bedingungen festgelegt, die das 

10 Debugging starten (vgl. Breakpoint nach dem Stand der Tech- 
nik) . Das Auftreten der Bedingungen wird zur Lauf zeit in der 
VPU und/oder einem beliebigen mit der VPU datenaustauschenden 
Gerat f estgestellt . Dies geschieht beispielsweise durch das 
Auftreten von bestimmten Datenwerten bei bestiininten Variablen 

15 und/oder bestimmten Triggerwerten bei bestimmten PAEs . 

1.1.2 Vorbedingunq 

Im Optimalfall kann eine bestimmte Bedingung gemali o.g. Defi- 
20 nition bereits mehrere Takte vor dem Eintreffen der Debug- 
Bedingung durch den Programmierer festgelegt werden. Dadurch 
werden bestimmte Latenz-Probleme, die im folgenden diskutiert 
werden, von vornherein ausgeschlossen. 

25 Es sollen im folgenden zwei grundlegende Arten des Debuggings 
fiir VPUs diskutiert werden, wobei die jeweils bevorzugt anzu- 
wendende Methode von der Wahl des Compilers abhSngt: 
Fiir Compiler, die Code auf Basis von instantiierten Modulen 
einer Hardwarebeschreibungssprache (oder ahnlichen Sprache) 

30 generieren, kann sich besonders die im folgenden beschriebene 
Methode A eignen. 
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Fiir Compiler ahnlich DE 101 39 170.6 und Zusatzanmeldungen, 
die komplexe Instruktionen erzeugen und nach einem VLIW- 
ahnlichen Verfahren generieren, eignet sich besonders die ira 
folgenden beschriebene Methods B. GrundsStzlich ist fur den 
5 Betrieb einer VPU Oder eines entsprechenden Bausteins als 
Prozessor oder Coprozessor Methode B die bevorzugt anzuwen- 
dende . 

Es wurde erkannt, dass insbesondere die Verwendung beider Me- 
10 thoden A und B gemeinsam zu den besten und transparentesten 
Debuggingergebnissen fuhrt. Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunachst unter Zuhilfenahme der 
schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fehlers sodann per Methode A die De- 
15 tails in der "Tiefe" analysiert werden. 

2. ttethode A 

20 2.1 Grundprlnzip 

Nach dam Auftreten einer (Vor ) Bedingung wird die VPU angehal- 
ten. Danach werden die relevant en Debug- Informationen aus den 
PAEs an das Debug- Programm tibertragen. Die relevanten Debug- 
Inf ormationen wurden zuvor durch den Programmierer innerhalb 

25 des Debug-Prograinmes festgelegt. Nach Auslesen aller relevan- 
ter Debug-Inf ormationen wird der nachste Takt ■ ausgeftihrt und 
erneut die relevanten Debug-Inf ormationen ausgelesen. Dies 
wiederholt sich solange, bis der Programmierer den Debug- 
Vorgang abbricht. Anstelle des Anhaltens der VPU sind eventu- 

30 ell andere Verfahren denkbar. So konnen fUr eine gegebene Ab- 
folge von Takten wiederholt Daten zum Auslesen bereitgestellt 
werden, sofern dies schnell genug moglich ist. 
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2.2 Un-bers-biitzung durch die Hardwaxe 
2.2.1 Auslesen der Register 

Wesentlich fiir die Funktionsweise des Debuggers ist die Mog- 
5 lichkeit, durch eine ubergeordnete Einheit (im folgenden De- 
bugProzessor (DB) genannt) , also beispielsweise eine CT oder 
Ladelogik, einen anderen extern angeschlossenen (Host)Pro- 
zessor oder einen reservierten Arraybereich, die internen Da- 
tenregister und/oder Statusregister und/oder Zustandsregister 

10 und ggf . je nach Implement ierung weitere relevante Register 
und/oder Signale aus den PAEs und/oder dem Netzwerk zurUckzu- 
lesen bzw. dies niir fur ausgewahlte Register bzw. Signale zu 
tun (zusammengef afit im folgenden als Debuginf ormation be- 
zeichnet) . Eine derartige Moglichkeit ist z. B. mit der in 

15 der PCT/DE 98/00334 geschaffenen Verbindung zwischen der 

Ladelogik und dem Datenbus einer PAE (PCT/DE 98/00334 0403, 
Fig. 4) realisierbar . 

Es soil ausdriicklich angemerkt sein, dali auch serielle Ver- 
20 fahren zum Auslesen der Register verwendet werden konnen. 

Beispielsweise kann JTAG gewahlt werden und der DB tlber die- 
ses Verfahren ggf. auch als externes seperates und evtl. auch 
marktubliches Gerat (z. B. Firma Hitex, Karlsruhe) ange- 
schlossen sein. 

25 

Da bevorzugt auf samtliche Register, oder ziimindest eine er- 
heblich Anzahl derer, durch den Debugger schreibend und/oder 
lesend zugegriffen werden kann, kann optional und bevorzugt 
ein wesentlicher Teil der (seriellen) Verkettung der Register 
30 zu Testzwecken (Scan-Chain) fiir die Produktionstests des 

Chips entf alien. Die Scan-Chain wird normalerweise dafur ver- 
wendet, um alle Register innerhalb eines Chips wahrend der 
Produktionstests mit Testdaten vorladen zu k6nnen und/oder 
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die Inhalte der Register zu Testzwecken wieder zurtickzulesen. 
Das Vorladen und/oder Zurticklesen geschieht dabei typischer- 
weise durch Testsysteme (z.B. SZ Testsysteme, Amerang) 
und/oder gemaB den in der DE 197 57 200.6-33 beschriebenen 

5 Verfahren. Die Scan-Chain benotigt dazu einen zusStzlichen 
nicht unerheblichen Hardware- und Flachenaufwand fur jedes 
Register. Dieser kann nunmehr, zumindest fiir die Register, 
die debugbar sind, entfallen, wenn - wie erf indungsgemaii vor- 
geschlagen - die Produktionstestanlagen uber geeignete 

10 Schnittstellen (z.B. parallel, seriell, JTAG, etc.) Zugriff 
auf die Register erhalten. 



2.2.2 Anhalten oder Verlangsamen des Taktes 

15 Durch das Auftreten von Bedingung und/oder Vorbedingung kann 
der Takt entweder angehalten oder verlangsamt werden, urn hin- 
reichend Zeit zum Auslesen zur VerfUgung zu stellen. Ausge- 
16st wird dieser Debugbeginn insbesondere entweder direkt 
durch eine PAE, die die (Vor) Bedingung (en) berechnete oder 

20 durch eine Qbergeordnete Einheit (z. B. Ladelogik/CT, Host- 
prozessor) aufgrund beliebiger Aktionen, beispielsweise durch 
die Information, daB an einer PAE eine (Vor) Bedingung auftrat 
und/oder durch eine Aktion innerhalb des DebugProzessors 
und/oder durch ein beliebiges Programm und/oder eine beliebi- 

25 ge externe/periphere Quelle. Zum Informieren stehen Trigger- 
mechanismen entsprechend P 44 16 881.0-53, DE 196 51 075.9- 
53, DE 197 04 728.9, DE 198 07 872.2, DE 198 09 640.2, DE 100 
28 397.7 zur Verftigung. Alternativ kann beim Debuggen der 
Takt generell verlangsamt werden. Sollen nur Arrayteile de- 

30 buggt werden, kann eine partielle Heruntertaktung vorgesehen 
werden. 
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Sofern der Takt verlangsamt wird, muss durch den Debugprozes- 
sor innerhalb des verlangsamten Zyklus des Verarbeitungst a ki- 
tes alls relevante Debug-Inf ormation aus den PAEs ausgelesen 
warden. Dazu ist es sinnvoll und bevorzugt, den Takt nur par- 
5 tiell zu verlangsamen, also den Arbeitstakt zu senken Oder 
anzuhalten, aber den Takt far den Auslesemechanismus weiter 
f ortzufahren. Des weiteren ist es sinnvoll und bevorzugt, ge- 
nerell die Register zum Datenerhalt mit Takt zu versorgen. 

10 Nach dem Anhalten des Taktes kann ein Single-Step Modus rea- 
lisiert werden, d.h. der Debugprozessor halt den Verarbei- 
tungstakt so lange an, bis er alle Debug- Information ausgele- 
sen hat. Danach startet er den Verarbeitungstakt wieder ftir 
einen Zyklus und halt ihn erneut bis nach dem Auslesen aller 

15 relevanten Debug-Inf ormationen an. 

Der Auslesetakt und der Takt des Debug-Prozessors sind bevor- 
zugt unabhangig vom Verarbeitungstakt der PAEs, so dafi die 
Datenverarbeitung vom Debugging und insbesondere Auslesen der 
20 Debug-Inf ormation getrennt ist . 

Hardwaretechnisch wird das Anhalten oder Verlangsamen des 
Taktes durch Methoden nach dem Stand der Technik, wie bei- 
spielsweise Gated-Clocks und/oder PLLs und/oder Teller oder 

25 andere Verfahren erreicht. Diese Mittel werden bevorzugt an 
geeigneten Stellen (Knoten) innerhalb des Clock-Trees einge- 
ftigt, so dafi eine globale Taktsteuerungen der jeweils tiefer- 
liegenden Zweige realisierbar ist. Die Heruntertaktung nur 
von ausgewahlten Arrayteilen ist in den unter Bezug genomme- 

30 nen Anmeldungen des vorliegenden Anmelders offenbart. 

Besonders bevorzugt ist das Versenden einer Taktsteuer- 
Infoinnation von einer iibergeordneten Einheit (z.B. Ladelo- 
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gik/CT, HostprozGssor) an sSmtliche bzw. samtliche zu debug- 
genden PAEs . Dies kann bevorzugt tiber das Konf igurationsbus- 
system erfolgen. Die Taktsteuerinf ormation wird dabei typi- 
scherweise gebroadcastet iibertragen, d.h. alle PAEs erhalten 
5 dieselbe Information. 



Beispielsweise konnen folgende Taktsteuerinf ormationen imple- 
mentiert sein: 

10 STOP: Der Arbeitstakt wird angehalten. 

SLOW: Der Arbeitstakt wird verlangsamt - 

STEP: Exakt ein Verarbeitungsschritt (Single Step Modus) 

wird ausgefiihrt und dann der Arbeitstakt wieder an- 
gehalten . 

15 STEP(n): n Verarbeitungsschritte werden ausgefuhrt und dann 
der Arbeitstakt wieder angehalten. 
GO: Der Arbeitstakt IMuft normal weiter. 



Es soil insbesondere erwahnt sein, dass das Verfahren der 
20 Taktabschaltung und/oder Verlangsamung ebenso eingesetzt wer- 
den kann, um den Stromverbrauch zu reduzieren. Sofern tempo- 
rar keine Rechenleistung benStigt wird, kann ein "Sleepmode" 
beispielsweise durch das Abschalten des Arbeitstaktes (STOP) 
Oder durch spezielle Befehle (SLEEP) realisiert werden. Wird 
25 nicht die voile Rechenleistung benotigt, kann der Takt durch 
die Verwendung von SLOW verlangsamt werden und/oder temporar 
durch STEP(n) ausgesetzt werden. Insoweit ist das Verfahren 
optional und/oder zusStzlich zu den in der DE 102 06 653.1 
beschriebenen Verfahren zur Reduzierung der Verlustleistung 
30 einsetzbar. 



Ein Problem des Broadcastings von Taktsteuerinf ormationen ist 
die Obertragungszeit des Broadcastes durch das Array aus 
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PAEs- Die Obertragung kann bei hoheren Taktf requenzen nicht 
innerhalb eines Arbeitstaktes erfolgen. Es ist aber zwingend 
notwendig, dass sSmtliche PAEs zur gleichen Zeit auf die 
Taktsteuerinformationen reagieren. Bevorzugt wird die Takt- 
5 steuerinf ormation daher Uber ein gepipelintes Bussystem ahn- 
lich des in DE 100 28 397.7 beschriebenen CT-Bussystems tiber- 
tragen. Weiterhin wird ein Zahlenwert (LATVAL) den Taktsteue- 
rinformationen hinzugeftigt der gleich oder grblier der maxima- 
len Lange der Pipeline des Bussystems ist. In jeder Pipeli- 

10 nestufe wird taktweise der Zahlenwert dekrementiert (Subtrak- 
tion von 1) . Jede PAE, die die Taktsteuerinf ormation erhalt, 
dekrementiert im weiteren den Zahlenwert mit jedem Takt. Da- 
mit ist sichergestellt, dass der Zahlenwert in dem gepipelin- 
ten Bussystem und den PAEs, die die Taktsteuerinf ormation be- 

15 reits empfangen haben, iramer exakt gleich ist. Erreicht der 
Zahlenwert den Wert 0, ist sichergestellt/ dafi alle PAEs die 
Taktsteuerinformation erhalten haben. Jetzt tritt die Takt- 
steuerinf oimation in Kraft und das Verhalten des Taktes wird 
entsprechend modifiziert. 

20 

Durch das beschriebene Verfahren entsteht eine weitere La- 
tenzzeit (Latency). Diese kann beispielsweise durch die nach- 
folgend beschriebene Registerpipeline zusatzlich abgefangen 
werden, oder, wie besonders bevorzugt, durch die Definition 
25 der (Vor) Bedingung abgefangen werden, indem die (Vor)Be- 
dingung soweit vorgesetzt wird, dafi die Latenzzeit bereits 
berUcksichtigt ist. 

Es soli besonders erwahnt werden, dali die Latenzzeit im Sin- 
30 gle-Step Modus vernachlassigbar ist, da sie nur bei der Ab- 
schaltung es Taktes (STOP) eine Rolle spielt. Da der Befehl 
STEP immer nur exakt einen Schritt ausfahrt, koimnt es wahrend 
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des Single-Step Betriebes durch keinerlei Verfalschung (Ver- 
zOgerung) der Debugdaten durch die Latenzzeit. 

5 2.2.3 Reqisterpipeline zxm. Ausgleichen der Latency 

Bei hSheren Betriebsfrequenzen kann es zu einer Latenzzeit 
zwischen dem Erkennen des Debugbeginns und dem Anhalten oder 
Verlangsamen des Taktes kommen. Diese Latenzzeit ist exakt 
vorherbestimmbar, da die Position der verzogernden Register 

10 in der VPU durch Hardware und/oder den zu debuggenden Algo- 
rithmus definiert und durch den Debugger daher exakt bere- 
chenbar ist . 

Durch die Latenzzeit verschieben sich jedoch die dem Debug- 
15 Prozessor zur VerfUgung gestellten Inf ormationen derart, dafi 
nicht mehr die korrekten Debuginf ormationen ausgelesen werden 
kSnnen. Bevorzugt wird dies durch ein entsprechendes Festle- 
gen der (Vor) Bedingung durch den Programmierer gel5st. Optio- 
nal kann durch das Einfugen einer mehrstuf igen Registerpipe- 
20 line, die die Debuginf ormation in jedem Takt um ein Register 
weiter tibertragt, der Debugprozessor auf so viele Takte an 
Debuginf oinnationen zuriickgreif en, wie die Registerpipeline 
lang ist. Die LSnge der Registerpipeline ist so auszulegen, 
daJi sie der maximal zu erwartenden Latenz entspricht. Auf- 
25 grund der exakten Berechenbarkeit der Latenzzeit ist es nun- 
mehr dem Debug- Programm mSglich, die zeitlich korrekte, rele- 
vante Debug-Inf ormation aus der Registerpipeline auszulesen. 

Ein auftretendes Problem bei der Verwendung von Registerpipe- 
30 lines ist, dali diese verhaltnismaJiig lang und damit, bezogen 
auf die fur die Realisierung notwendige Siliziumf ISche, teuer 
sind. 
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2.3 Slchtbace Debug- Znfozmalilonen 

Bei dieser Methode wird im wesentlichen nach Auftreten der 
5 (Vor)Bedingung debugt, da erst danach der Takt verlangsamt 
Oder angehalten wird und das Auslesen der Debug-Information 
erfolgt. Debug-Inf ormationen, die vor dem Auftreten der 
(Vor) Bedingung liegen, sind daher zunachst nicht sichtbar. 

10 Es ist jedochv wenngleich auch unter Verlust an Arbeitslei- 
stung, moglich eine VPU sofort vom Start einer Applikation an 
mit verlangsamten Takt oder Single-Step-Modus zu betreiben. 
Vom Start an werden die relevanten Debug-Inf oannationen vom 
Debug-Prozessor ausgelesen. 

15 

3. Methode B 
3.1 6run^ri.nzi.p 

20 

Relevante Debug-Inf ormationen aus den Speichereinheiten, die 
gemaU P 44 16 881.0-53, DE 196 54 846.2-53, DE 199 26 538.0, 
DE 101 39 170.6 und deren Zusatzanmeldungen, DE 101 10 530.4 
die Anwendungsdaten und Zustande eines bestimmten Arbeits- 

25 schrittes beinhalten, werden an das Debug-Programm iibertra- 
gen. Diese Speichereinheiten, nachfolgend auch Arbeitsspei- 
cher genannt, arbeiten im Maschinenmodell nach der P 44 16 
881.0-53, DE 196 54 846.2-53, DE 101 39 170.6 und deren Zu- 
satzanmeldungen, DE 199 26 538.0, DE 101 10 530.4 quasi als 

30 Register zur Speicherung von Daten, die innerhalb eines Kon- 
figurationszykluses im PA oder Teilen des PAs berechnet wur- 
den. Es wird insbesondere auf die Patentanmeldung DE 101 39 
170.6 und deren Zusatzanmeldungen verwiesen, in der die Ver- 
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wendung der Speichereinheiten als Register (REG) zur Reali- 
sierung eines Prozessormodells detailliert beschrieben ist. 
Die DE 101 39 170.6 und deren Zusatzanmeldungen sind zu Of- 
fenbarungszwecken vollximf anglich eingegliedert . Eine Spei- 
5 chereinheit besteht dabei aus einer beliebigen Anordnung und 
Hierarchie von unabhangigen und abhangigen Speichern. Es ist 
moglich, gleichzeitig mehrere unterschiedliche Algorithmen 
auf dem PA (Processing Array) auszufUhren, die dann unter- 
schiedliche Speicher verwenden. 

10 

Wesentlich fUr die Anwendung dieser Methode ist, dali Daten 
und/oder algorithmisch relevante ZustSnde in die den PAEs zu- 
geordneten Speichereinheiten abgelegt sind, wobei eine Spei- 
chereinheit jeweils zumindest derart dimensioniert ist, dali 
15 alle relevanten Daten und/oder ZustSnde eines Zyklus gespei- 
chert werden konnen; hierbei kann die Lange eines Zyklus 
durch die GroBe der Speichereinheit bestimmt sein und ist es 
bevorzugt auch (vgl. DE 196 54 846.2-53). Mit anderen Worten 
wird die Zyklusiange der Hardware angepaBt. 

20 

Unterschiedliche Daten und/oder ZustSnde werden derart in die 
Speichereinheiten gespeichert, daii diese eindeutig dem Algo- 
rithmus zugeordnet werden kbnnen. Dadurch kann der Debugger 
die relevanten Daten und/oder Zustande (Debug-Information) 
25 eindeutig identif izieren. 

Die relevanten Debug- Informationen konnen - insbesondere auch 
vorab - durch den Programmierer innerhalb des Debug-Pro- 
grairanes. festgelegt werden. Diese Debug-Inf ormationen werden 
30 aus den Speichereinheiten ausgelesen. Dazu stehen unter- 
schiedliche Methoden zur VerfUgung; einige MSglichkeiten wer- 
den nachfolgend naher beschrieben. Nach dem Auslesen aller 
relevanter Debug-Inf ormationen wird der nSchste Konfigurati- 
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onszyklus ausgefiihrt und erneut die relevanten Debug-Infor- 
mationen ausgelesen. Dies wiederholt sich so lange, bis der 
Prograramierer/ Debugger den Debug- Vorgang abbricht. 

5 Mit anderen Worten warden die relevanten Daten und/oder Sta- 
tus informationen nicht taktweise, sondern konf igurationsweise 
an den Debugger iibertragen. Dies geschieht aus den Spei- 
chereinheiten, die mit den Registern einer CPU vergleichbar 
sind. 

10 

3.2 Unters-bli-bzung durch die Hardware 

Wesentlich fiir die Funktionsweise des Debuggers ist die Mog- 
15 lichkeit, durch die CT oder einen anderen extern angeschlos- 
senen Prozessor (im Folgenden DebugProzessor (DB) genannt) , 
die beispielsweise auch interne (n) Arbeitsspeicher der VPU zu 
lesen. Eine derartige M5glichkeit ist z.B. durch den Anschlufi 
der CT an die Arbeitsspeicher zum Vorladen und Lesen der Da- 
20 ten und/oder durch die in der DE 199 26 538.0 beschriebene 

Verfahren zum Herausschreiben der internen Speicher an exter- 
ne Speicher gegeben. In einer mogliche Ausgestaltung kann auf 
Arbeitsspeicher durch verschieden Verfahren nach dem Stand 
der Technik (z.B. Shared Memory, Bank Switching) derart vom 
25 DebugProzessor zugegriffen werden, dass der Datenaustausch 

mit dem DB weitestgehend unabhangig von einer weiteren Daten- 
verarbeitung in der VPU erfolgen kann. 

In einer moglichen Ausgestaltung kann z. B. entsprechend Me- 
30 thode A durch eine oder mehrere der vorstehend beschriebenen 
MaBnahmen der Takt der VPU zum Auslesen der Speicher gegebe- 
nenfalls entweder entsprechend verlangsamt oder angehalten 
werden und/oder gegebenenfalls im Single-Step-Modus betrieben 
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werden. Dabei kann je nach Implementierung der Arbeitsspei- 
cher, z. B. beim Bank-Switch-Verf ahren, auf einen besonderen 
Eingriff in den Takt verzichtet werden. Typischerweise ge- 
schieht das Anhalten oder Verlangsamen des Taktes nach Metho- 
5 de B und das Auslesen und/oder Kopieren und/oder Umschalten 
der Arbeit sspeicher nur, wenn ein Datenverarbeitungszyklus 
bzw. Konfigurationszyklus beendet ist. 

Mit anderen Worten ist ein wesentlicher Vorteil von Methods 
10 B, dass keine besondere Unterstiitzung durch die Hardware er- 
forderlich ist. . 

In einer m5glichen Ausgestaltung muii ein DB lediglich Zugriff 
auf die Arbeitsspeicher besitzen. In einer besonders zu be- 
15 vorzugenden Ausgestaltung geschieht der Zugriff auf die Ar- 
beitsspeicher -durch eine geeignete Konf iguration der VPU, die 
dadurch die Arbeitsspeicher selbstandig und ohne Modifikation 
ausliest und an einen DB tibertragt. 

20 

3.3 Zug-rxff bxi£ Debug- Xxxfoxmation 

In der P 44 16 881.0-53, DE 196 54 846.2-53, DE 101 39 170.6, 
DE 199 26 538.0 sind Datenverarbeitungsverf ahren beschrieben, 

25 bei denen zyklisch eine Menge an Operationen auf einen rekon- 
f igurierbaren Datenverarbeitungsbaustein abgebildet werden. 
In jedem Zyklus wird eine Mehrzahl von Daten berechnet, die 
von einer peripheren Quelle und/oder einen internen/externen 
Arbeitsspeicher stairanen und an eine periphere Quelle und/oder 

30 einen internen/externen Arbeitsspeicher geschrieben werden. 

Dabei k5nnen jeweils unterschiedliche und/oder vor allem meh- 
rere unabhangige Arbeitsspeicher gleichzeitig verwendet wer- 
den. Beispielsweise konnen in diesem Datenverarbeitungsver- 
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fahren die Arbeitsspeicher oder ein Teil der Arbeitsspeicher 
als Registersatz dienen. 

Nach der DE 101 39 170.6 und der DE 199 26 538.0 werden dabei 
5 samtliche Daten und Zustande, die fur die weitere Datenverar- 
beitung relevant sind, in die Arbeitsspeicher abgelegt 
und/oder aus selbigen gelesen. In einem bevorzugten Verfahren 
werden ftir die weitere Datenverarbeitung irrelevante Zustande 
nicht gespeichert . 

10 

Die Unterscheidung zwischen relevanten und irrelevant en Zu- 
standen soli an folgendem Beispiel aufgezeigt werden, es soli 
zu Offenbarungszwecken dabei insbesondere auf die Ausftihrun- 
gen in der DE 101 39 170.6 verwiesen werden: 

15 

Die Zustands information eines Vergleichs ist beispielsweise 
fiir die weitere Verarbeitung der Daten wesentlich, da dieser 
die auszuftihrenden Funktionen bestiirant. 

20 Ein sequenzieller Dividierer entsteht beispielsweise durch 
Abbildung eines Divisionsbef ehles auf eine Hardware, die nur 
die sequenzielle Division unterstUtzt. Dadurch entsteht ein 
Zustand, der den Rechenschritt innerhalb der Division kenn- 
zeichnet. Dieser Zustand ist irrelevant, da ftir den Algorith- 

25 mus nur das Ergebnis (also die ausgefiihrte Division) erfor- 
derlich ist. In diesem Fall werden also lediglich das Ergeb- 
nis und die Zeitinf ormation (also die Verftigbarkeit) ben6- 
tigt. 

30 Die Zeitinf ormation ist beispielsweise in der VPU-Technologie 
nach P 44 16 881.0-53, DE 196 51 075.9-53, DE 199 26 538.0 
durch das RDY/ACK Handshake erhaitlich. Hierzu ist jedoch be- 
sonders anzumerken, daft das Handshake ebenfalls keinen rele- 
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vanten Zustand darstellt, da es lediglich die Giiltigkeit der 
Daten signalisiert, wodurch sich wiederum die verbleibende 
relevate Information auf die Existenz gUltiger Daten redu- 
ziert . 

5 

In der DE 101 39 170.6 wird eine Unterscheidung zwischen lo- 
kal und global relevanten Zustanden aufgezeigt: 

lokal: Der Zustand ist nur innerhalb einer einzigen abge- 
10 schlossenen Konf iguration relevant. Daher muS» der Zustand 
nicht zwingend gespeichert werden. 

global: Die Zustandsinf ormation wird fiir mehrere Konfigura- 
tionen benotigt. Der Zustand muB gespeichert werden. 

15 Es ist nunmehr denkbar, daJi der Prograininierer einen lokal re- 
levanten Zustand debuggen will, der nicht in den Speichern 
abgelegt ist. In diesem Fall kann die Applikation dahingehend 
modifiziert werden, daB eine Debug-Konf iguration entsteht 
{aquivalent zum Debug-Code von Prozessoren) , die eine Modifi- 

20 kation zum "normalen" Code der Applikation derart aufweist, 
dali dieser Zustand zusatzlich in die Speichereinheit ge- 
schrieben und damit dem Debugger zur VerfUgung gestellt wird. 
Dadurch entsteht eine Abweichung zwischen Debug-Code und tat- 
sSchlichera Code, die zu einem unterschiedlichen Verhalten der 

25 Codes ftihren kann. 

In einer daher besonders bevorzugten Ausftihrung wird keine 
Debug-Konf iguration verwendet. Vielmehr wird die zu debuggen- 
de Konf iguration derart terminiert, dass die fur Debugging- 
30 zwecke zusatzlich erf orderlichen Daten die Terminierung uber- 
dauern, d.h. weiterhin gtiltig in den entsprechenden Speicher- 
stellen (REG) (z.B. Register, zahler, Speicher) verbleiben. 
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Wenn die zu debuggende Konf iguration derart terminiert wird, 
daB die fUr Debugging-Zwecke zusStzlich erf orderlichen Daten 
die Terminierung liberdauern, ist es moglich, ein Debuggen 
einfach dadurch durchzuf iihren, daB nicht die nachste, bei 
5 no2rmalem Prograiranablauf erforderliche Konf iguration geladen 
wird, sondern stattdessen eine Konf iguration, liber welche die 
zu den Debugging- Zwecken erf orderlichen Daten in die Debug- 
Einheit bzw. das Debug-Mittel iibertragen werden. Es sei dar- 
auf hingewiesen, daJi bei einem solchen Debuggen auch im spa- 

10 teren Ablauf des Programmes stets die zu Debug-Zwecken erfor- 
derlichen Daten mit abgespeichert werden konnen, wodurch si- 
chergestellt ist, daB das spater ausgefiihrte Programm in ex- 
akt der Weise einem Debug-ProzeB unterworfen wurde wie erfor- 
derlich. Nach Auslesen der Debug-Inf ormation durch eine dedi- 

15 zierte Debug-Konf iguration kann dann mit der normalen Pro- 
grammausfiihrung fortgefahren werden - 

Eine Konf iguration wird geladen, diese verbindet die REG in 
geeigneter Weise und definierter Reihenfolge mit einem Oder 
20 mehreren globalen Speicher(n), auf die der DB Zugriff hat 
(z.B. J\rbeitsspeicher) . 

Vorgeschlagen wird also, daB eine Konf iguration geladen wird, 
diese die REG in geeigneter Weise verbindet und in definier- 
25 ter Reihenfolge mit einem oder mehreren globalen Speichern 
verbindet, auf die der DB Zugriff hat (z. B. Arbeitsspei- 
cher) . 

Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
30 wenden, um auf den/die globalen Speicher zuzugreifen. Die 
Konf iguration kann beispielsweise Adressgeneratoren verwen- 
den, um auf als Speicher ausgestaltete REG zuzugreifen. Ent- 
sprechend der konf igurierten Verbindung zwischen den REG wer- 
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den die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jeweiligen 
Adressen von Adressgeneratoren vorgegeben werden. Der Adress- 
generator generiert die Adressen fur den/die globalen Spei- 
cher (n) derart, dafi die beschriebenen Speicherbereiche (DEBU- 
GINFO) der entfernten zu debuggenden Konf iguration eindeutig 
zugeordnet werden kSnnen. 

Das Verfahren entspricht dem Kontext-Switch in DE 102 06 
653.1 und DE 101 39 170.6, die zu Of f enbarungszwecken volliim- 
fanglich eingegliedert sind. 

Der DB kann nunmehr auf die Daten innerhalb eines ihm zugMng- 
lichen Speicherbereiches (DEBUGINFO) zugreifen. Soil das De- 
bugging mittels eines Single-Step Verfahrens durchgeftihrt 
werden, kann nach jedem single step einer zu debuggenden Kon- 
figuration ein Kontext-Switch derart durchgeftihrt werden, 
dass samtliche Daten erhalten bleiben und die zu debuggende 
Information aus den REG in einen Arbeitsspeicher geschrieben 
wird. Sodann wird wiederum unter Erhalt der Daten die zu de- 
buggende Konfiguration wieder konfiguriert und fxir einen wei- 
teren single step ausgefUhrt. Dies geschieht fiir jeden zu de- 
buggenden single step der zu debuggenden Konfiguration. Auf 
die Moglichkeit eines Debugging unter Verwendung der als „Wa- 
ve-Rekonf iguration'^ bekannten Prinzipien sei hingewiesen. 

3.4 Slchtbare Debug- Informa-felonen 

Ein Debuggen vor der (Vor) Bedingung kann vergleichsweise ein- 
fach und ohne groBe Perf ormance-Verluste durchgefuhrt werden 
da die ben5tigten Debug- Informationen in Arbeit sspeichern 
verfiigbar sind. Durch das Ubertragen der Arbeitsspeicher in 
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andere Speicherbereiche, auf die der DB bevorzugt direkten 
Zugriff hat, kann die Debug-Inf ormation einfach sicherge- 
stellt werden. Eine noch schnellere Methode ist, die Arbeits- 
speicher durch ein Bank-Switching-Verf ahren (nach dem Stand 
5 der Technik) derart zwischen den einzelnen Konf igurationen 
.umzuschalten, dafi die Debug-Inf ormation in einer jeweils neu- 
en Bank liegt. Das Umschalten kann sehr zeitoptimierend, im 
Optimalfall sogar ohne Auswirkung auf die Verarbeitungslei- 
stung erfolgen. 

10 

Es ist bereits offenbart worden, daB bei einer VPU Daten 
blockweise in einen Speicherbereich abertragen werden kSnnen. 
Dieser kann auch auJierhalb des eigentlichen PA liegen 
und/oder einen Dual-Ported-RAM oder dergleichen aufweisen, so 
15 dafi es moglich ist, auf die eingeschriebene Information von 
aufien leicht zuzugreifen. 



4 . Funk-fc±onswe±se des Debuggers 

20 

Das Debugger-Programm selbst kann auf einem DB aufierhalb des 
PAs ablaufen. Alternatiy dazu kann eine VPU selbst den DB 
darstellen, entsprechend der Methoden, die bei Prozessoren 
angewendet werden. Dazu kann ein Task- oder Kontextswitch 

25 (SWITCH) entsprechend den Ausfuhrungen in PACTll ausgefUhrt 
werden. Die Debuginformationen des zu debuggenden Programmes 
werden bei einem SWITCH zusammen mit den relevanten Daten ge- 
sichert und das Debugger Programm geladen, das die Informa- 
tionen auswertet unc^/oder interaktiv mit dem Programmierer 

30 verarbeitet. Danach wird erneut ein SWITCH durchgefahrt (bei 
welchem die relevanten Inf ormationen des Debuggers gesichert 
werden) und das zu debuggende Programm wird weitergeftihrt . 
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Es sei auch erwahnt, daB als Debugger ein Prozessor-Teil- 
bereich vorgesehen werden kann. 

Die Debug-Inf ormation wird vom Debugger entsprechend Methode 
5 A und/oder B gelesen und in einen von der Datenverarbeitung 
separaten Speicher und/oder Speicherbereich gespeichert, auf 
den der DB bevorzugt direkten Zugriff besitzt. Durch das De- 
bugger- Programm werden die Breakpoints und (Vor) Bedingungen 
definiert. Ebenfalls kann das Debugger- Programm die Kontrolle 
10 liber die Ausfiihrung der Applikation, insbesondere den Ausfiih- 
rungsstart und das Ausftihrungsende Ubernehmen. 

Der Debugger stellt dem Programmierer eine geeignete Arbeits- 
lamgebung zur Verfiigung mit ggf. graphischer Oberflache. In 

15 einer besonders bevorzugten Ausfiihrung ist der Debugger in 

eine komplexe Entwicklungsumgebung integriert und tauscht mit 
dieser Daten und/oder Steuerinf ormation aus. Insbesondere 
kann der Debugger die aus den Arbeitsspeichern gelesenen Da- 
ten zur beliebigen Weiterverarbeitung auf einen Datentrager 

20 (Festplatte, CDROM) speichern und/oder innerhalb eines Netz- 
werkes (wie Ethernet) ablaufen. 

Der erf indungsgemaiie Debugger kann zudem gemMfi DE 101 29 
237.6-53 innerhalb einer Entwicklungsumgebung mit anderen 

25 Werkzeugen und insbesondere auch Debuggern kqmmunizieren; wo- 
bei in einer bevorzugten Ausgestaltung die Steuerung und/oder 
Definition der Debugparameter von einem anderen Debugger aus 
Qbernoramen werden kann. Ebenso kann der Debugger die von ihm 
generierte Debug-Inf ormation einem anderen Debugger zur Ver- 

30 ftlgung stellen und/oder von diesem dessen Debug-Information 
erhalten. 
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Insbesondere das Feststellen des Auftretens von Breakpoints 
und/oder (Vor) Bedingung ist durch einen anderen Debugger bzw. 
den Einheiten, die dieser andere Debugger debugt, durchfiihr- 
bar. Der erf indungsgemaiie Debugger und die VPU reagieren dann 
5 entsprechend. 

Der andere Debugger kann insbesondere der Debugger eines mit 
einer VPU gekoppelten anderen Prozessors (CT, bzw. ARC bei 
Chameleon, Pentium, AMD usw.) sein. 

10 

Insbesondere kann der andere Debugger auf einem der VPU zuge- 
ordneten und/oder gekoppelten Prozessor ablaufen und/oder der 
zugeordnete Prozessor der DB sein, beispielsweise eine CT 
bzw. ARC bei Chameleon. In einer besonders bevorzugten Ausge- 
15 staltung kann der zugeordnete Prozessor ein Host-Prozessor 
sein, wie beispielsweise in der 60/317,876 und/oder der DE 
102 06 856.9 beschrieben. 

20 5. Bewertung der Me-bhoden 

Die Methode A ist erheblich zeit- und ressourcenintensiver 
als die Methode B, bei der kaum zusatzliche Hardware erfor- 
derlich ist und zudem ggf . das zeitaufwendige Auslesen der 
25 Debug-Information vom Start der Applikation an entfallt. Da- 
her ist Methode B grundsatzlich vorzuziehen. Fiir Compiler 
nach DE 101 39 170.6 und deren Zusatzanmeldungen ist die Me- 
thode B eindeutig zu praferieren. 

30 Es wurde erkannt, daJi insbesondere die Verwendung beider Me- 
thoden A und B gemeinsam zu den besten und transparentesten 
Debuggingergebnissen ftihrt. Insbesondere kann je nach Tiefe 
des zu debuggenden Fehlers zunSchst unter Zuhilfenahme der 
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schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fehlers sodann per Methods A die De- 
tails in der "Tiefe" analysiert werden. 

6. Miaced Mtode Debugger 

Bei der Anwendung der besonders bevorzugten Methods B kann as 
zu dem Problem koiranen, dass die in den Speichern befindliche 
sichtbare Information nicht hinreichend ist. 

Typischerweise kann ein detaillierteres Debugging folgender- 
massen erfolgen: 

a) Die sichtbare Debuginf ormation (PREINFO) vor der Konfigu- 
ration einer einen Breakpoint enthaltenden Konf iguration 
wird gesichert. Bei Auftreten eines Fehlers bei dem Bre- 
akpoint wird die dann sichtbare Debuginf ormation (POSTIN- 
FO) gesichert. Basierend auf der PREINFO Information wird 
ein Software-Simulator gestartet, der die zu debuggen- 
de(n) Konf iguration (en) simuliert. Der Simulator kann da- 
bei jeden Wert innerhalb der PAEs und der Bussysteme be- 
stimmen und (ggf- auch graphisch und/oder textuell) aus- 
geben, wodurch ein detaillierter Einblick in den Ablauf 
des Algorithmus zum Zeitpunkt des Auftretens des Fehlers 
erreicht wird. Insbesondere ist es moglich, die jeweils 
simulierten Werte mit den Werten von POSTINFO zu verglei- 
chen, um Differenzen schnell zu erkennen. 

b) Die sichtbare Debuginf ormation vor einem Breakpoint wird 
gesichert. Bei Auftreten eines Breakpoints wird basierend 
auf dieser Information ein Sof tware-Visualisierer gestar- 
tet. Der zu debuggende Baustein wird nunmehr in einem 
Single-Step Verfahren betrieben, das das Auslesen samtli- 
cher relevanter Daten nach Methode A ermOglicht. Diese 
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Daten kSnnen nunmehr entweder direkt (ggf- auch graphisch 
und/oder textuell) ausgegeben werden und/oder an einen 
Simulator weitergeleitet werden, dessen Simulation sodann 
auf den detaillierteren Daten beruht, und danach wie be- 
kannt ausgegeben werden. 

6.1 Vorteile eines Mixed-Mbde-Debuggers 

Der Mixed-Mode-Debugger ermoglicht die detaillierte Analyse 
der Ablaufe innerhalb eines Bausteines. Durch die MSglichkeit 
gemSB Methode B, bis zu einem gesetzten Breakpoint mit voller 
Geschwindigkeit zu arbeiten und danach ggf. anzuhalten, zu 
verlangsamen und/oder ggf. in einen Single-Step-Modus zu ge- 
hen, wird das Debugging zeitef f izient, wodurch das Testen 
grofier Datenmengen und/oder komplexer Algorithmen ermoglicht 
wird. Das bevorzugte Aufsetzen eines Simulators nach dem Auf- 
treten des Breakpoints auf Basis der aktuellen Daten und Zu- 
stande ermoglicht einen genauen Einblick in die Hardware. So- 
fern der Zeitaufwand fur die Simulation zu hoch ist und/oder 
die 100% Obereinstimmung des Simulators mit der Hardware 
fraglich ist, ermoglicht das Zurucklesen von Daten im Single- 
Step-Modus nach Auftreten eines Breakpoints gemafi Methode A 
Oder entsprechend des Kontext-Switch Verfahrens nach DE 102 
06 653.1 und DE 101 39 170.6 ein 100% korrektes Debugging des 
Algorithmus und/oder auch der Hardware selbst. 

7 . Beschreibtmq der Fiquren 

Figur 1 und 2 entsprechen der Patentanmeldung DE 101 39 
170.6. Die unterschiedlichen AnsStze der Methoden A und B 
wurden in die Figuren eingezeichnet (A, B) 
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Pigur lb zeigt eine Reprasentation des endlichen Automaten 
durch eine rekonf igurierbare Architektur nach P 44 16 881.0- 
53 und DE 196 54 846.2-53 (DE 196 54 846.2-53, Fig. 12-15). 
Das kombinatorischen Netz aus Figur la (0101) wird durch eine 
Anordnung von PAEs 0107 ersetzt (0101b) . Das Register (0102) 
wird durch einen Speicher (0102b) ausgefiihrt, der mehrere Zy- 
klen speichern kann. Die ROckkopplung gemafi 0105 erfolgt 
durch 0105b. Die Eingange (0103b bzw. 0104b) sind equivalent 
0103 bzw 0104. Der direkte Zugriff auf 0102b kann ggf. durch 
einen Bus durch das Array 0101b realisiert werden. Der Aus- 
gang 0106b ist wiederum Equivalent 0106. 

Pigur 2 zeigt die Abbildung eines endlichen Automaten auf ei- 
ne rekonf igurierbare Architektur. 0201 (x) reprasentieren das 
kombinatorische Netz (das entsprechend Figur lb als PAEs aus- 
gestaltet sein kann) . Es existiert ein oder mehrere Speicher 
fQr Operanden (0202) und ein oder mehrere Speicher ftir Ergeb- 
nisse (0203) . Zusatzlich Daten Ein-/Ausgange gem. 0103b, 
0104b, 0106b) sind der Einfachheit halter nicht dargestellt. 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204, 0205) . 

Die Operanden- und Ergebnisspeicher (0202, 0203) sind physi- 
kalisch oder virtuell derart miteinander verkoppelt, dafi bei- 
spielsweise die Ergebisse einer Funktion einer anderen als 
Operanden dienen kOnnen und/oder Ergebnisse und Operanden ei- 
ner Funktion einer anderen als Operanden dienen kOnnen. Eine 
derartige Kopplung kann beispielsweise durch Bussysteme her- 
gestellt werden oder durch eine (Re) Konf iguration, durch wel- 
che die Funktion und Vernetzung der Speicher mit den 0201 neu 
konfiguriert wird. 
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Pigur 3 zeigt eine mogliche schematische Struktur des Debug- 
gings nach Methode B. Es sei insbesondere beispielhaft auf 
die Figuren 19, 20, 21 der Patentanmeldung DE 199 26 538.0 
verwiesen, in welcher die Grundlage der Speicher beschrieben 
5 ist. Die DE 199 26 538.0 wird hiermit zu Of f enbarungszwecken 
vollumfanglich eingegliedert . 

0101b und 0102b ist wie bereits beschrieben dargestellt. Zu- 
satzlich ist eine externer Speichereinheit dargestellt 

10 (0302), der moglicherweise ahnlich DE 199 26 538.0 an 0102b 
angeschlossen (0307) sein kann. Es soil besonders darauf hin- 
gewiesen werden, dafi sowohl 0102b als auch 0302 externe Oder 
interne Speichereinheiten sein konnen. Ebenfalls soli eine 
Speichereinheit als mindestes ein Register, eine Menge von 

15 Registern oder ein Speicher (RAM, Flash, o.a.) oder Massen- 
speicher (Festplatte, Band, o.a.) definiert sein. 

Die debuggende Einheit 0301 kann Breakpoints innerhalb 0101b 
setzen (0303) , auf Basis derer der eigentliche Debug Vorgang 

20 ausgelCst wird. Durch das Erreichen eines Breakpoints wird 
eine Information (0304) an 0301 gesendet, die den Debug Vor- 
gang startet; zugleich werden auch alle 0101b intefenen Vor- 
kehrungen zum Debuggen (z.B. ein Anhalten und/oder Verlangsa- 
men des Taktes) ausgelost. Alternativ kann auch durch 0301 

25 die Information generiert und an 0101b gesendet werden. 

Ober 0305 und/oder 0306 kann 0301 auf die Daten und/oder Zu- 
stande aus dem Speicher 0102b und/oder dem Speicher 0302 zu- 
greifen. Der Zugriff kann zum Beispiel 

1. durch eine Speicher kopplung (Block-Move, d.h. kopieren 

30 der Speicher in einen anderen, von 0301 kontrollierten 

Bereich) , 
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durch eine Leitung (serielle oder parallele Leitung, 
tiber die ein oder mehrere Speicherbereich (e) ubertragen 



5 



3 



wird/werden, z.B. JTAG) , 

Buskopplungen gleich welcher Art (die Speicher warden 
ahnlich eines DMA-Verf ahren arbitriert und von 0301 ver- 



arbeitet) 



erf olgen. 

Als Beispiel wurde eine Figur aus der DE 199 26 538.0 ge- 
iO wahlt. Es soil ausdriicklich darauf hingewiesen werden, dafi 

grundlegend jedes Speicherverf ahren und jede Speicher kopplung 
(Stack, Random-Access, FIFO, usw.) entsprechend bearbeitet 
werden kann. 

15 Die Figuren 4a und 4b zeigen weitere mQglichen Ausgestaltun- 
gen und wurden aus der Patentanraeldung DE 102 06 856.9 ent- 
nommen, die zu Of f enbarungszwecken vollumf Snglich eingeglie- 
dert ist- 

20 Der Aufbau einer besonders bevorzugteri- VPU ist in Figur 4a 

dargestellt. Vorzugsweise hierarchische Konf igurationsraanager 
(CT's) (0401) steuern und verwalten eine Anordnung von rekon- 
figurierbaren Elementen (PACs) (0402). Den CT's ist ein loka- 
ler Speicher fiir die Konf igurationen zugeordnet (0403) . Der 

25 Speicher verfiigt weiterhin uber ein Interface (0404) zu einem 
globalen Speicher, der die Konf igurationsdaten zur Verfagung 
stellt. Ober ein Interface (0405) sind die Konf igurationsab- 
lauft steuerbar. Ein Interface der rekonf igurierbaren Elemen- 
te (0402) zur Ablauf steuerung und Ereignisverwaltung (0406) 

30 ist vorhanden, ebenso ein Interface zum Datenaustausch 
(0407). Beipielsweise kann eine der CT's als DB agieren. 
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Flgur 4b zeigt einen Ausschnitt aus einem beispielhaften CPU- 
System, beispielsweise einem DSP des Types C6000 von Texas 
Instruments (0451). Dargestellt sind Prograiranspeicher (0452), 
Datenspeicher (0453), beliebige Peripherie (0454) und EMIF 
(0455) . Uber einen Speicherbus (0456) und einen Peripheriebus 
(0457) ist eine VPU als Coprozessor integriert (0458) . Ein 
DMA-Kontroller (EDMA) (0459) kann beliebige DMA-Transfers, 
beispielsweise zwischen Speicher (0453) und VPU (0458) oder 
Speicher (0453) und Peripherie (0454) durchfiihren. In diesem 
Beispiel kann 0451 als DB arbeiten und insbesondere auch der 
erfindungsgemafie Debugger mit des sen Debugger gekoppelt 
und/oder in diesen integriert sein. 

Fxgur 5a zeigt einen beispielhaften Hardwareaufbau, der zum 
Debuggen von rekonf igurierbaren Prozessoren benutzt werden 
kann. Hierzu wird ein gepipelinter Konf igurationsbus 0501 
verwendet, ahnlich dem aus DE 100 28 397.7 bekannten. Die 
Pipeline ist iiber mehrere Register stuf en (0502) in horizonta- 
ler und/oder vertikaler Richtung aufgebaut, urn hohere Takt- 
frequenzen zu erreichen. Der gepipelirite Konf igurationsbus 
fiihrt zu den zu konf igurierenden Elementen (PAEs) (0503), um 
diese mit Konf igurationsdaten zu versorgen. 

Figur 5b zeigt beispielhaft die erf orderliche Erweiterung ge- 
maB der vorliegenden Erfindung. Jede Registerstuf e (0502) de- 
krementiert den Zahlenwert (LATVAL) zum Ausgleich der Latenz- 
zeit um 1 (angedeutet durch -1) . Ebenso dekrementiert jede 
PAE (0503), die bereits eine Taktsteuerinformation erhalten 
hat, diese pro Takt um 1 (angedeutet durch -1/T) . Auf die 
PAEs und insbesondere deren internen Register kann nunmehr 
nicht nur schreibend, sondern auch lesend zugegriffen werden 
z.B. iiber eine besondere Steuerleitung (RD) , um Debugdaten 
auszulesen. Zu schreibende und gelesene Daten durchlaufen in 
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diesem Beispiel das Bussystem durch das Array aus PAEs von 
links nach rechts und in der untersten Zeil^ in Rtick- 
wartsrichtung. Der Konf igurationsbus ist weiterhin Uber Regi- 
sterstufen (0505) pipelineartig zurtickgef tihrt (0504) . In die- 

5 sem Beispiel kann eine ubergeordnete Einheit (CT/Ladelogik, 
Hostprozessor) (0506) ebenso lesend und schreibend auf den 
Bus zugreifen, wie ein dediziertes Testinterface (0507) . Das 
Testinterface kann einen eigenen Testkontroller aufweisen und 
insbesondere kompatibel zu einem oder mehrern marktgangigen 

10 Testschnittstellen sein (z.B. JTAG, Tektronix, Rhode&Schwarz, 
etc) . Die Auswahl der bussteuernden Einheit erfolgt ttber eine 
Multiplexer/Demultiplexer-Einheit (0508) . In (0509 in Klam- 
mern und kursiv dargestellt) oder vor den Einheiten 0506 und 
0507 kann eine Schaltung zur Ruckrechung der Herkunf tsadresse 

15 (0509) von Debugdaten, die iiber 0504 eintreffen, vorgesehen 
sein. Die Adressberechnungen innerhalb des aufgezeigten Sy- 
stems geschehen wie folgt: Zunachst wird die Adresse durch 

0506 Oder 0507 am Bus 0501 angelegt. Die Adresse wird ahnlich 
der Verarbeitung der Zahlenwerte (LATVAL) zur Latenzberech- 

20 nung in jeder Registerstuf e (0502 und 0505) dekrementiert . 
Sobald die Adresse gleich 0 ist, wird die nach der Register- 
stuf e liegende PAE selektiert. In der nachf olgenden Register- 
stuf e wird die Adresse negativ, so dafi keine weiteren PAEs 
mehr aktiviert werden. Sofern Daten aus einer PAE gelesen 

25 werden, werden diese zusammen mit der Adresse zuriickubertra- 
gen. Die Adresse wird dabei in jeder Registerstuf e weiter de- 
krementiert. Eine Riickrechnung in 0509 der bei 0506 und/oder 

0507 zusammen mit den Debugdaten eintref f endeij Adressen ist 
nunmehr durch eine einfache Addition moglich, indem die An- 

30 zahl der dekrementierenden Registerstuf en zu dem eintreffen- 
den Adresswert hinzuaddiert werden. Es soil angemerkt sein, 
dass die Registerstufen 0502 in Figur 5b leicht unterschied- 
lich gegenaber den Registerstufen 0502 in Figur 5a ausgestal- 
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tet sind. In Figur 5b weisen diese namlich zusatzlich eine 
Schaltung (z.B. Multiplexer) zu Auswahl der weiterzuleitenden 
Daten auf , der entweder die Daten des Busses 0501 weiter- 
schaltet oder den Ausgang der zugeordneten PAE (0503) und so- 
5 mit die DebugDaten. Zur Ansteuerung der Schaltung kann das 
Auftreffen des Adresswertes gleich 0 dienen. 

Es wird nochmals darauf hingewiesen, dali das dedizierte Te- 
stinterface (0507) den Industriestandards entspricht. Es kann 

10 zu Tests wahrend des Software-Debug- Vorgangs eingesetzt wer- 
den und/oder zu Test wahrend des Zusanimenbaus von Hardware- 
komponenten und -systemen (z.B. dem Zusamraenbau der Schaltun- 
gen auf der Platine) und/oder zu Funktionstests des Halblei- 
terbausteins (Chips) im Rahmen der Halbleiterfertigung. Ins- 

15 besondere dadurch kann die iibliche Scan-Chain zum Test der 

Register wShrend des Funktionstests des Halbleiters entfallen 
Oder zumindest entsprechend minimiert werden, da dann nur die 
Register durch die Scan-Chain geftlhrt werden mUssen, die 
nicht vom Bus system (0501) ansteuerbar sind. 

20 

Ebenfalls wird besonders darauf hingewiesen, dafi das in Figur 
5 erlauterte Verfahren keinesfalls auf die Anwendung bei Kon- 
f igurationsbussen beschrankt ist. GewShnliche Datenbussysteme 
kSnnen ebenso zu den unterschiedlichen vorab aufgezahlten 

25 Test- und Debugging-Zeitpunkten und -arten verwendet werden. 
Insbesondere sei in diesem Zusammenhang auf das in der DE 197 
04 742.4 beschriebene Datenbussystem hingewiesen. Die DE 197 
04 742.4 ist hierzu zu Of f enbarungszwecken vollumf anglich 
eingegliedert . Die in Figur 5 beschriebenen Verfahren konnen, 

30 ftir einen Ingenieur mit gewohnlichen technischen Kenntnissen 
leicht nachvollziehbar ebenso auf die DE 197 04 742.4 ange- 
wendet werden. 
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Ein Mischbetrieb unterschiedlicher Bussysteme, wie Konfigura- 
tionsbussystemen, Datenbussystemen nach DE 197 04 742.4 und 
gewShnlichen Datenbussystemen ist desweiteren grundsatzlich 
moglich. Dazu konnen mehrere Testinterf ace vorgesehen sein, 
5 Oder wie technisch bevorzugt die Multiple- 

xer/Demultiplexerstuf e (0508) auf eine Mehrzahl von Bussyste- 
men (n x 0501, n x 0504) ausgelegt werden. 



AbschlielSend soli noch besonders erwShnt sein, dass durch die 
10 Ruckfiihrung des Bussystems nach Figur 5b auch die in die PAEs 
zu schreibenden Konf igurationsdaten zurtickgef iihrt werden. Un- 
ter Zuhilfenahme der Adressriickrechung (0509) und der zurtick- 
gefahrten Statusleitung RE J, die nach DE 100 28 397.7, DE 198 
07 872.2, DE 196 54 593.5-53 eine Zuruckweisung der Konfigu- 
15 rationsdaten anzeigt, kann auf die Verwendung der Konfigura- 
tionszwischenspeicher-FIFOs nach DE 100 28 397.7 Figuren 8 
und 9 (0805, 0903) verzichtet werden, da deren FunktionalitSt 
nunmehr vollumf anglich uber das beschriebene Bussystem abge- 
bildet wird. 
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lofcal relevant:er Zust:and 

5 

global relevan'ber Zustand 

10 

relevantec Zusliand 

15 

xrrelevan-bec Zus-band 

20 
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Zustand, der nur innerhalb einer 
bestimmten Konf iguration relevant 
ist > 

Zustand, der in mehreren Konfigu- 
rationen relevant ist und zwi- 
schen den Konf igurationen ausge- 
tauscht werden muJi. 

Zustand, der innerhalb eines Al- 
gorithmus zur korrekten AusfUh- 
rung dessen benotigt wird und so- 
mit durch den Algorithmus be- 
schrieben ist und verwendet wird. 

Zustand, der fur den eigentlichen 
Algorithmus ohne Bedeutung ist 
und auch nicht im Algorithmus be- 
schrieben ist, der jedoch von der 
ausfiihrenden Hardware implemen- 
tierungsabhangig benOtigt wird. 
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Titel: Verfahren zum Debugger! rekonf igurierbarer 

Architekturen 



Patentansprache 

1. Verfahren zum Debugger! von rekonf igurierbarer Hardware, 
dadurch gekennzeichnet, dafi sSmtliche notwendige Debug- 
information je Konf igurationszyklus in einen Speicher ge- 
schrieben werden, der dann vom Debugger ausgewertet wird. 

2. Verfahren nach dem vorhergehenden Anspruch, dadurch ge- 
kennzeichnet, dali wahrend des Debug-Vorganges nach Auf- 
treten einer Debug-Bedingung, geitiSfi welcher Information 
uber die zu debuggende Konf iguration benotigt wird, eine 
Konfiguration geladen wird, mittels welcher die in den 
Speicher geschriebenen Debug-Inf ormationen ausgelesen und 
insbesondere in eine Debug-Einheit oder Debug-Konf igura- 
tion geschrieben werden. 

3. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daB eine zu debuggende Konfigurati- 
on vor dem Ablauf des Debugging derart verSndert wird, 
dali bei normaler, nicht-debuggender Ausfiihrung nicht er- 
forderliche Information in einem Speicher abgelegt wird. 

4. Verfahren nach einem der vorhergehenden AnsprQche, da- 
durch gekennzeichnet, daB zum Auslesen die Taktfrequenz 
zumindest verlangsamt oder angehalten wird und/oder eine 
taktweise Abarbeitung der zu debuggenden Konfiguration 
Schritt fur Schritt erfolgt. 
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5. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daS> die zu debuggende Konf iguration 
nach Auslesen der relevanten Information oder nach davor- 
liegender Infoimvation simuliert wird. 

5 

6. Vorrichtung mit einem Feld konf igurierbarer Elemente, 
insbesondere grobgranularer logischer und/oder arithmeti- 
scher Einheiten sowie einem Debug-Mittel zum Debuggen von 
Programmen, Programmteilen oder auf dem Array auszufiih- 

10 renden komplexen Operationen, dadurch gekennzeichnet, dafi 

das Debug-Mittel ein Speichermittel zur Speicherung von 
fur das Debugging relevanten Informationen wShrend oder 
am Ende eines Arbeitsschrittes des Feldes konf igurierba- 
rer Elemente umfaBt, wobei das Speichermittel zum Debug- 

15 ging auslesbar ist. 

7 . Vorrichtung nach dem vorhergehenden Anspruch, dadurch ge- 
kennzeichnet, daB das Speichermittel als Dual-Ported-RAM 
mit einem ersten Eingang fur abzuspeichernde Infoirmation 

20 aus dem Prozessorf eld und einem zweiten Eingang ziom Aus- 

lesen der Information in ein Analysemittel ausgebildet 
ist. 
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